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Abstract 

In classical ChP{FD) systems, domains of variables are completely known at the beginning 
of the constraint propagation process. However, in systems interacting with an external 
environment, acquiring the whole domains of variables before the beginning of constraint 
propagation may cause waste of computation time, or even obsolescence of the acquired 
data at the time of use. 

For such cases, the Interactive Constraint Satisfaction Problem (ICSP) model has been 
proposed ICucchiara et al. 1999all as an extension of the CSP model, to make it possible 
to start constraint propagation even when domains are not fully known, performing ac- 
quisition of domain elements only when necessary, and without the need for restarting the 
propagation after every acquisition. 

In this paper, we show how a solver for the two sorted CLP language, defined in previous 
work lIGavanelli et al. 20041 to express ICSPs, has been implemented in the Constraint 
Handling Rules (CHR) language, a declarative language particularly suitable for high level 
implementation of constraint solvers. 

1 Introduction 

Constraint Logic Programming on Finite Domains {CLP (FD)) represents one of the 
most successful implementations of declarative languages. By means of constraints, 
the user can give the specifications of a combinatorial problem and possibly solve 
it, exploiting efficient propagation algorithms. GLP{FD) languages have been suc- 
cessfully used for solving a variety of industrial and academic problems. However, 
in some constraint problems, where domain elements need to be acquired, it may 
not be wise to perform the acquisition of the whole domains of variables before the 
beginning of the constraint propagation process. For instance, in configuration prob- 
lems IjMailharro 1 998' 'IL OC 1999|l domain elements represent components, which 
have to be synthesized before being used. The set of components is not known 
beforehand, and sometimes even the size of the set cannot be estimated. Often, 
a minimization of the set of components is required, thus the constraint solver 
produces a new component only when it is strictly necessary. 

In systems that need to interact with an external environment, domain elements 
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can be produced by an acquisition system that retrieves information about the outer 
world. An example is given by Faltings and Macho- Gonzalez (2003) where Internet 
applications are faced and obviously not all the information can be computed before 
starting the constraint satisfaction process. As another example, consider a visual 
search system IjCucchiara et al. 1999b|l where domain elements are basic visual fea- 
tures (like segments, points, or surface patches) extracted from the image. In a 
classical CLP(f£') computation, all domain values must be known when defining 
the variables, so all the possible visual features would have to be extracted before 
starting the visual search process, even if only a small subset of them will be actu- 
ally used. The synthesis of visual features is usually very time consuming, because 
the information encoded with signals must be converted into symbolic form. Thus, 
the extraction of domain elements that will not be used can result in a significant 
waste of computation time. Also, in systems that interact with an evolving environ- 
ment, full acquisition of all the domain elements is not wise HBarruffi et al. 1999|l . In 
fact, if all the possible information is acquired beforehand, some of the information 
might be obsolete at the end of the acquisition. 

For all these reasons, a new model called Interactive Constraint Satisfaction 
Problem (ICSP) has been proposed IjCucchiara et al. 1999a|l as an extension of the 
widely used Constraint Satisfaction Problem (CSP) model. In an ICSP, domains 
consist of a known part, containing the available elements, plus a variable that 
semantically represents a set of values that could be added to the domain in the 
future. In a sense, in an ICSP, domains can be considered as streams of information 
from one system to the constraint solver. Constraint propagation can be performed 
even when the domains are not completely known, and domain values can be re- 
quested from an acquisition system during constraint propagation; in other words, 
constraint propagation and value acquisition interact (thus Interactive in the name 
of the framework) and are interleaved, whereas in classical CSP frameworks domain 
elements are completely known before the beginning of the propagation. In this way, 
the acquisition system can possibly extract only elements consistent with the im- 
posed constraints, thus focusing the attention only on significant data. Various prop- 
agation algorithms have been proposed l|Cucchiara et al. 200111 for exploiting the 
available information and acquiring new domain values only when strictly necess- 
ary. Reducing the number of extracted elements can provide a notable speedup 
HCucchiara et al. 1999a|l . 

In l|Gavanelli et al. 2004|l we describe a corresponding CLP language. Our lan- 
guage is two sorted. The first sort is the classical sort on Finite Domains (FD). The 
second sort, called I-Set, is based on a structure similar to streams, and represents 
domains of the FD variables. From the constraints on the FD sort, the system can 
start propagation before having full knowledge of domain elements. Each element 
will be inserted on demand in the domain, without having to restart constraint 
propagation from scratch. Moreover, constraints can be imposed on domains, thus 
helping the user defining I-Sets""^ declaratively. In this paper, we present an imple- 

^ In this article, the T-Set notation (with caUigraphic I) will denote the sort, while the notation 
I-Set (with non-calligraphic I) will denote a particular I-Set. 
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mentation of the two-sorted language in Constraint Handling Rules (CHR). CHR 
(^Friihwirth 19981 is a declarative language for defining new constraint solvers at a 
very high level. CHR can be used for rapid prototyping, and has proven effective 
in various real life applications. The purpose of this paper is to show how Con- 
straint Handling Rules can be effectively used to implement the solver for our two 
sorted ICSP-based language. In previous work IjCucchiara et al. 199 9a). the propa- 
gation algorithms have been proposed and separately implemented, but we did not 
describe the full implementation of the solver for ICSP problems. The algorithms 
were implemented using non fully declarative constructs (e.g., metaterms with de- 
structive assignment). The high level, declarative encoding in CHR consists of a 
solver for the X-Set sort, a solver for the FD sort, and an interface between them 
designed to exploit the advantages of the ICSP model in systems interacting with 
external acquisition modules. 

Of course, other aspects in the model of a problem, besides domain elements, 
could be unknown; in a CSP there could be unknown variables or unknown con- 
straints. Typically, in all Constraint Programming systems new constraints can be 
easily added, while removal of constraints is more complex IjPechter and Dechter 1988)1 . 
The addition of variables has been taken into account by Dynamic CSP mod- 
els UMittal and Falkenhainer 1990|l . Our work is focussed on unknown domain el- 
ements, and proposes an interaction based on the acquisition, from an external 
system, of domain elements. 

The rest of the paper is organized as follows. The declarative and operational 
semantics of the language defined by Gavanelli et al. I)2004|l are briefly recalled 
in Section |2 In Section 13 we describe the architecture of the language from an 
implementation viewpoint, and in Section^ we show how it is implemented in the 
CHR language. Discussion of related work (including a detailed comparison with 
UMailharro 1998|l . which is very related to our work from the operational viewpoint) 
and conclusions follow. 



2 SyntEix and Semantics 

The language defined in l|Gavanelli et al. 2004)1 is based on a two sorted CLP, where 
the first sort is the classical sort on Finite Domains (FD) and the second is the sort 
on Z-Set. I-Sets are used both as domains for FD variables and as communication 
channels with an external source providing elements. 

In this section, we briefly recall the syntax and semantics of the language. 

In the following, we comply to the conventions in (IJaffar et al. 1998*1. In particu- 
lar, every constraint domain C (where C can be FD, T-Set, or FD+T-Set) contains: 
the constraint domain signature Sc, the class of constraints Cq (a set of first-order 
E-formulas), the domain of computation Vc (a E-structure that is the intended 
interpretation of constraints), the constraint theory 7c (a S-theory that describes 
the logical semantics of the constraints), and the solver solve- 
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2. 1 The I -Set sort 

The X-Set sort is meant to provide domains for variables in the FD sort. Domains 
are thus considered as first-class objects, and they can be declaratively defined by 
means of constraints. In a sense, they can be considered as streams, but they are in- 
trinsically non-ordered, and do not contain repeated elements. Declaratively, I-Sets 
are sets; thus unification and constraints should consider I-Set terms modulo the 
set theory IIDovier et al. {A\{A\B}} = {A\B}, {A\{B\C}} = {B\{A\C}}, 

which states that sets do not contain repeated elements and order is not important. 
Non-ground elements are forbidden in an I-Set; this restriction can be exploited for 
more efficient propagation algorithms. In fact, we represent an I-Set as the union 
of a set of ground elements (which we name the known part of the I-Set) and a 
variable representing its unknown part. 

In CLP(Z-Set), the constraint domain signature, "^x-Set^ contains the following 
constraints: 

• s-niember{E, S) 4^ E e S, 

• union{A, B, C) <=> A\J B ^ C , 

• mtersection{A, B , C) <^ Ar\ B ^ C , 

• diSerence{A, B,C) A\B ^ C, 

• inclusion{A, B) A C B, 

where E represents a ground term, and A, B, and C represent I-Sets. 

The operational semantics of the X-Set sort is defined in terms of state of I-Sets, 
primitives used to check and modify the state, and events over I-Sets. 

The state of an I-Set is defined by its known part, i.e. the set of the elements which 
are known to belong to the I-Set (as opposed to its unknown part, representing 
the elements which have not yet been acquired for the I-Set), and its open-closed 
condition, i.e., an I-Set is open if new elements can be inserted into it, closed 
otherwise. 

A convenient notation to express the state of an I-Set is one based on Prolog-like 
lists. An I-Set is represented by a structure S defined by S ::= {}, or S ::= {T\S}, 
or S ::— V, where T is a ground term and is a variable. 

The known part of an I-Set is the set of all the ground elements in the list 
representing it; an I-Set is closed if its continuation (tail) is ground, open otherwise. 
For example, I-Set {1,2,3,4|T} is open, and its known part is the set {1,2,3,4}; 
I-Set {1,2,3,4} has the same known part, but it is closed. 

We have primitives to modify and check the state of an I-Set. Two primitives are 
used to modify the state, namely: 

• ensurejmemher (Element, Iset): enforces Element to be a member of the known 
part of Iset, possibly adding it if it is not already member, or failing if it is 
not already member and the I-Set is closed; 

• close(Iset): closes Iset; after execution of this primitive, no new elements can 
be added to the I-Set. 

The following primitives are used to check the state of an I-Set: 
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• known(Iset,KnownPart): KnownPart is the list of elements in the known part 
of Iset; 

• is_closed(Iset): checks if the Iset is closed. 

An event is a notification of how the status of the computation has been modified, 
which may be relevant for the rest of the computation and is to be processed 
properly. The semantics of an event is defined by rules specifying its interactions 
with the constraints in the store. It is quite apparent that the concept of event finds 
a natural representation as a CHR constraint; nevertheless, we prefer, in defining the 
operational semantics of the language, to keep events and proper X-Set constraints 
distinct. The concept of event makes it possible to express the semantics of Z-Set 
constraints with simple (CHR-like) rules. For example, this rule is all that is needed 
to define the fact that, in the inclusion/2 constraint, all elements in the first I-Set 
also appear in the second: 

inserted(Element , Isetl), inclusion{Isetl, Iset2) =^ 
ensure -member [Element , Iset2) 

This rule simply states that, if the inserted(Element,Isetl) event is raised (i.e., 
if Element has been inserted into Isetl) and Isetl is known to be included in 
Iset2, the propagation process must make sure that the element is also present 
in Iset2. This may imply the insertion of Element into Iset2, with a subsequent 
inserted(Element,Iset2) event, if Iset2 is open and Element is not already a member, 
or a failure, if Iset2 is closed and Element is not already a member. 

Propagation of closure can also be managed with ease. For instance, the rule 

closed{Iset2), inclusion{Iset\, Iset2), 

known(Isetl, Kl), known{Iset2) , K2 =^ , , 

permutation{Kl, K2)\ 

close{Iset\) 

states that if Isetl C Iset2, Iset2 is closed (as indicated by the closed(Iset2) event), 
and the known elements in Isetl are all the known elements in Iset2, then also 
Isetl is closed (by the close(Isetl) primitive). 



2.2 The FD sort 

The FD sort shares the same declarative semantics of the classical FD sort. Thus, 
the usual constraints in CLP(FD) are considered (arithmetic, relational constraints 
plus user-defined constraints). We suppose that the symbols <,<,+,— ,x,... be- 
long to S_F_D and are interpreted as usual. 

Since we want cope with incompletely specified variable domains avoiding use- 
less value acquisition, we use a constraint propagation based on the available 
knowledge, when domains are still partially specified. For this reason, we proposed 
l|Gavanelli et al. 2004|l an extension, for the partially known case, of the concept 
of consistency, called known consistency. In this paper, we provide only the defini- 
tion of node and arc-consistency; the extension to higher degrees of consistency is 
st r aight forward . 
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Definition 2.1 

A unary constraint c{Xi) is known node-consistent iff 

Vw, e K[, V, e c{X,), 

where is the known part of the domain oi Xi. A binary constraint c{Xi, Xj) is 
known arc-consistent iff 

e e if/ s.t. {v^, vj) e c(X,,Xj), 

where K[ and are the known parts of the domains of Xi and Xj, respectively. 
A constraint network is known arc-consistent (KAC) iff all unary constraints are 
known node-consistent and all binary constraints are known arc-consistent. 

The following proposition shows the link between known arc- consistency and arc- 
consistency l|Mackworth 1977|l . The proof can be found in IjGavanelli et al. 2004|l . 

Proposition 1 

Every algorithm achieving KAC (i.e. any algorithm that computes an equivalent 
problem that is KAC) and that ensures at least a known element in each vari- 
able domain is able to detect inconsistency in the same instances as an algorithm 
achieving AC. 

In other words, if there exists an arc-consistent sub-domain, then there exists a 
maximal arc-consistent sub-domain; so if KAC does not detect inconsistency, AC 
will not detect inconsistency either. 

KAC is equivalent to AC when domains are completely known. The advantage 
in using KAC is that the check for known arc-consistency can be performed lazily, 
without full knowledge of all the elements in every domain. 

2.3 Linking the two sorts 

Intuitively, we want to bind CLP(f D) with CLP(Z-Set) with the intended semantics 
that TSets provide domains for FD variables. 

Given the two CLP languages Cfd and 'Cj_gg^, we define the CLP language C 
as the union of the two languages, with a further constraint, :: , defined as follows: 

• the signature S = U Ej_gg|- U { :: }; 

• the intended interpretation T) keeps the original mappings in the FD and 
Z-Set sorts; i.e., I'Isfd = T^fd and = 2^i_Set- 

The declarative semantics of the constraint is 

X :: S ^ X (^S 

where X is a FD variable. The :: /2 constraint links a FD variable to its domain 
as in most CLP{FD) frameworks, with the difference that S, being and I-Set, 
may be non-completely specified. The :: /2 constraint should not be confused with 
the s-meniber/2 constraint of Section [2.11 which represents the constraint of set 
membership between a ground element and an I-Set. 
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Fig. 1. FD Constraints as filters on variable domains 



In CLP(i^D) systems, domains provide ancillary information about variables. Do- 
mains contain the possible values that a variable can take; if a value is not consistent 
with the imposed constraints, it is operationally removed from the domain. This 
helps many systems fPinc bas et al. 1988l|Puget 1994|IT(!;-Parc 2001IISIUStus 200"3|l 
to obtain higher performance; in fact, domain wipe-outs are detected early and 
many alternatives are efficiently pruned. On the other hand, in the X-Sct sort, do- 
mains must be manipulated as logical entities: if an element declaratively belongs 
to a domain, it cannot be removed. 

Suppose that we have constraint {1, 2, 3} C £) stating that the elements 1, 2 and 
3 should belong to the set D, the constraint X :: D that links variable X to the 
domain D, and X ^ 1 that states that X should be different from 1. Usual constraint 
propagation of the constraint X ^ I would remove element 1 from the domain D, 
but this is inconsistent with the constraint {1, 2, 3} C £) so the computation would 
fail. This behavior is not correct, because the set of constraints {1,2,3} C D, 
X € D, and X ^ 1 is satisfiable. 

For this reason, in our framework, the domain of a variable X is represented 
by two streams: a Definition Domain, D^, that contains all the values synthesized 
for the variable, and a stream of Removed Values, , that is the set of elements 
proven to be inconsistent with the imposed constraints. The set of available items 
for X , also called Current Domain, D^, is given by the relation: 

(2) 

It should be noticed that remains open until is closed. D"^, instead, is always 
open, so to make it possible to move elements into it from the current domain even 
if the definition domain has been closed. 

With the imposed constraints, it is possible to declaratively add a newly synthe- 
sized value to the definition domain (imposing the constraint v E D^) or remove an 
inconsistent element from the current domain (w ^ or, equivalently, w £ D^; 
see Fig.nj. In this way, during search, an inconsistent element will not be tried if it 
belongs to D'^ and a possible domain wipe-out will be detected when is empty. 
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Note that the relation in Eq. (0) automatically propagates two types of informa- 
tion from the definition domain to the current domain of a variable. First, whenever 
a domain element is synthesized, it is considered in the current domain and can be 
exploited for propagation. Second, if no more values are available to the definition 
domain, also the current domain becomes closed. 

Notice that more than one FD variable can range on the same definition domain 
or, equivalently, their definition domains can be linked by an equality constraint; 
however, each of them will have its own current domain and set of removed values. 
By definition, the user cannot close the current domain of a variable: the user should 
only access the definition domain directly. This is not a restriction, because if one 
wants to close independently the current domain of different variables (as in the 
previous example), he can define two different definition domains (and, possibly, 
impose some constraints among them, e.g., C Dy)- 

In order to achieve KAC, it is necessary to remove elements and to promote 
elements, i.e., to move ideally some elements from the unknown part to the known 
part. Elements can then be removed (i.e., prevented from entering the current 
domain) if they are shown to be inconsistent. An algorithm for achieving KAC is 
shown in l|Gavanelli et al. 2004|l . 

The addition, besides the deletion, of elements to the domain might seem non 
monotonic. However, the current domain is kept open as long as new acquisitions are 
possible (i.e., mitil the definition domain is closed), the unknown part representing 
the set of future acquisitions. Thus, declaratively, when a new element enters the 
known part of the current domain, it is not properly added: it is just made explicit. 
A similar behavior is also achieved by Mailharro H1998fl with the use of a wildcard 
representing values entering the domain. 

Clearly, the repeated acquisition of the same element would result in a loop; 
this can be avoided by having an acquisition module that does not provide twice 
the same element to the same TSet (as hypothesized, for instance, by Mailharro 

Example: Numeric CSP. Various applications could be thought exploiting inter- 
active constraint propagation, as many systems need to interact with an exter- 
nal environment during propagation: some real-world examples can be found in 
IjCavanelli et al. 2 004 ) . In this section, we give a simple example, aimed at showing 
a typical ICSP computation, rather than at showing the power of the language. 
With the given language, we can state in a natural way the following problem: 

:-X :: Dx, Y :: Dy,Z :: D z, inter section{Dx ■, Dy , Dz), Z > X- 

defining three variables, X , Y , and Z , with constraints on them and their domains. 
KAC propagation can start even with domains fully unknown, i.e., when Dx, Dy 
and Dz are variables. Let us suppose that the elements are acquired through in- 
teraction with a user and the first element retrieved for A" is 1. This element is 
inserted in the definition domain of A, i.e., = {lj(£)^)'}; since it is consistent 
with FD constraints, it is not redirected to the D"^ stream; value 1 is considered 
in the current domain, i.e., — {1|(D^)'}. Then KAC propagation tries to find 
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a support for this element in each domain of those variables linked by FD con- 
straints; in our instance Dz- A value is requested for Dz and the user gives a 
(possibly consistent) value: 2. This element is inserted into the definition domain of 
Z: = {2|(Z)|)'}. The constraint imposed on domains can propagate, so element 
2 has to be inserted in the definition domain of Y and X, thus Dy = Dy = {2|Dy} 
and D-^ ^ ^ {l,2\D'j,}. 

Since the acquired element is consistent with FD constraints involving Z , it enters 
the current domain of Z. KAC propagation must now find a known support for 
element 2 for X , so another request is performed. If the user replies that there is 
no other element in the domain of Z, then 2 is sent to the stream of removed values 
for X (thus, it is not considered in the current domain of X). It will remain in the 
definition domain because the element semantically belongs to the domain even if 
no consistent solution can exist containing it. 

When KAC propagation reaches the quiescence, each element of the current do- 
main of each variable has a support for each FD constraint involving that variable. 

3 Implementation concepts 

Since one of the aims of the ICSP model is to manage efficiently those problems 
in which value acquisition is costly, it is useful to exploit the link between the two 
sorts to avoid unnecessary acquisition of domain elements. For instance, as shown 
in the example in Section 12.31 it is possible to infer the presence of a value in the 
known part of an I-Set from X-Set constraints, without acquiring it directly. 

Thus, for the sake of efficiency, the implementation of the language must be aware 
of the link between the two sorts, given by the :: /2 constraint (see Section . 
and exploit it when useful. Nonetheless, the two sorts are clearly distinct, and need 
to be handled by different computational mechanisms. 

In more detail, it is possible to devise two constraint solvers: one for the FD sort, 
meant to ensure KAC (see Def. 12.1(1 of the FD constraint network, and one for the 
T-Set sort, meant to ensure satisfaction of I-Set constraints. 

These solvers only need to interact in two cases: 

• when, during FD KAC check, a new element is acquired, X-Set propagation 
must be activated in order to satisfy X-Set constraints; 

• conversely, when a new element enters the known part of an I-Set, FD KAC 
check must be activated over all the FD variables which have their definition 
domain in the I-Set. 

The CHR language is a perfectly suitable tool for this purpose, letting us deal with 
the two sorts separately, and to manage the link between them with ease. 

3.1 FD sort concepts 

The aim of the FD solver is to keep the constraint network known arc-consistent. 
This is achieved by preventing elements from entering current domains if no KAC 
support is found for the constraints involving them. In more detail, each time a new 
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Fig. 2. State transitions for [Variable, Element) pairs 



element E is promoted from the unknown to the known part of an I-Set C, it is 
inserted into the definition domain of each variable V such that V :: C {E G Dy 
with the notation of Sect. 12. 3() . The algorithm then tries to find a KAC support 
for E: if support is found, then E is also inserted into the Current Domain of V 
{E € Dy); otherwise, although it stays in the definition domain of V, it enters the 
stream of Removed Values for V {E € Dy). 

In this way, at any step of the propagation, all of the values in current domains 
are certainly supported. 



3.1.1 Values' .states 

The process described above can be clearly formalized as a sequence of state tran- 
sitions for {V, E) pairs. These states are: 

• unknown: E has not yet been acquired as a value for V; 

• candidate: E has been inserted into Dy, but {V,E) has not yet been chosen 
for supporting another value and no KAC control is being run on it; 

• observed: {V , E) provides support for some other observed pair, but it has not 
yet been proven to be supported; 

• present: {V, E) is supported, and has thus been inserted into Dy-, 

• removed: E is not supported, and has thus been inserted into Dy. 

The possible state transitions are shown in Figure El 



3.1.2 Lazy value acquisition 

The ICSP framework is more suitable for those applications in which the process 
of acquiring domain values is computationally costly. In this perspective, the KAC 
check procedure has been designed so as to acquire new values only when it is 
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really necessary, i.e., when no support for a value can be found among already 
known values. 

3.2 T-Set sort concepts 

The task performed by the X-Set solver is to ensure the satisfaction of the Z-Set 
sort constraints, and to propagate the closure of definition domains, when possible. 
As shown in the example below, it is possible to infer that an element belongs 
to an I-Set from X-Set sort constraints, thus reducing the number of necessary 
acquisitions and improving efficiency. 

In particular, each time an element is added to an I-Set, an inserted /2 event 
(see Section 12.1(1 is raised, which starts a check for the satisfaction of the X-Set 
constraints involving the I-Set itself. 

Example Let us suppose the constraint inter section[D x,D y ,Dz) is given among 
the Dx^ Dy and Dz I-Sets, and that the current values of the domains are 

Dx - {2A\D'x}; Dy - {3A\D'yh Dz = {4|i?^}. 
If 5 is added to Dz^ the system immediately ensures 5 to be a member of both 
Dx and Dy, without the need for acquiring the element. If 3 is added to Dz, the 
system only needs to add it to Dx ■ Conversely, if 3 is added to Dx , it is also added 
to Dz] if 1 is added to Dx, instead, the system cannot infer anything, and thus 
makes no additions. 

X-Set constraints also have to be taken into account to propagate closure of I-Sets, 
when possible (as in the example shown in Sect. \'2.l}i . For this purpose, we use a 
closed /I event, which notifies that an I-Set has been closed. 

3.3 Interaction between sorts 

The link between the two sorts, represented by the :: /2 constraint (sec Section 
I2.3|l . is implemented as an interaction mechanism between the solvers activated 
when, on the one hand, a new element is acquired during a KAC check and, on the 
other hand, an element is inserted into an I-Set. 

Semantically, we use the inserted/ 2 event for both of these cases (see Section lTTll . 

At the implementation level, the event causes the control to pass from one solver 
to another. 

3.4 Algorithms 

3.4-1 Priority among supporting values 

A (Variable, Element) pair is supported if, for each constraint involving Variable, 
support is found in the known part of other variables' domains. But supporting 
pairs may not be supported in their turn: this implies that, if a pair is found to 
be unsupported, new support needs to be found for all of the pairs that it was 
supporting. For efficiency, we keep track of which pairs support which other pairs 
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for which constraints, so that, in case a pair is found unsupported, it is possible to 
revise only the affected constraints. 

However, because of states (see Sect. l3.imi . it is possible to reduce the number of 
supports to keep track of. If an element is supported by an element whose state is 
present^ there is no need for keeping track of the support, because a present element 
is already known to be supported, as explained in Sect. 13.1.11 Thus, when seeking 
support for a constraint, present elements should be tried first. 

Likewise, an element whose state is observed is more convenient than an element 
whose state is candidate, because the algorithm is already seeking support for it, 
and can thus avoid seeking support for a new element (note that all candidates will 
eventually be checked; but in this way, when their turn comes, there will be, in 
general, more present elements). 

So, a priority can be established among eligible supporting elements: first present, 
then observed, then candidates. Only when no support is found among these ele- 
ments, a new element needs to be acquired: if the definition domain of the corre- 
sponding variable is open, an element can be requested, otherwise the support seek 
procedure fails. 

3.4-2 The support graph 

Support dependencies can be represented by a (directed) support graph, in which 
nodes represent observed (Variable, Element) pairs, and arcs represent support de- 
pendencies. 

When a candidate pair becomes observed, the corresponding node is added to the 
graph. This may happen at the beginning of graph construction, when the graph is 
empty and the candidate is chosen to be the first node, or later, during the support 
seeking procedure, if the candidate provides support for an observed. 

A new node needs support for the FD constraints involving it. For each FD 
constraint, the following attempts, in this order (see Sect. 13.4. l|l are made, until 
one succeeds: 

1. support is found in present elements only: the graph needs no modifications; 

2. one of the supporting elements is observed: an arc is added from the support- 
ing node to the supported, marked with the constraint; 

3. one of the supporting elements is candidate: a new node is added for the 
candidate, an arc is added from the supporting node to the supported, marked 
with the constraint. 

If none of these attempts succeeds, a variable (other than Variable) is chosen for 
acquisition among those involved by the constraint, and the search for support is 
restarted from the support-in-candidates attempt (step 3). The search for support 
needs to be restarted because, in order to satisfy X-Set constraints, new candidates 
may have been added, which may provide support for the considered FD constraint. 

A node is deleted from the graph if it is found to have no support; in this case, 
new support is sought for all of the nodes that it was supporting. 

Once a graph is fully built, all of its nodes can be inserted into the current 
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domains (observed-to-present transition), whereas the unsupported nodes will be 
inserted into the stream of removed values. 

The procedure reaches quiescence only when there are no more candidates to 
search support for. 

4 CHR implementation 

In this section, we show how the concepts explained in Section |21 have been im- 
plemented in a constraint solver using the Constraint Handling Rules library of 
SICStus Prolog. 

4-1 T-Set variables and constraints 

I-Sets are represented by CHR variables: these variables (also "link variables" here- 
after) act as a link for the information stored in constraints, and are never instan- 
tiated. To keep memory of the state of I-Sets we use CHR constraints, meant to 
interact in order to ensure satisfaction of X-Set constraints. 

The state of an I-Set is represented by means of three CHR constraints: 
iset-known(Iset, Known) links an I-Set to its known part, iset-open(Iset) indicates 
that the I-Set is open (i.e., other elements can be inserted), and closed(Iset) indi- 
cates that the I-Set is closed. 

An I-Set is created by the user either explicitly (new_iset_object/3 predicate) 
or implicitly, imposing constraint icsp_def-domain/2 (which implements the :: /2 
constraint of Sect. l2.3|l between an FD variable and the link variable of an I-Set. It 
is possible to define the domain as empty or as having a starting known part. 

Each constraint among I-Sets (see Section 12.11 for the formal definitions) is 
represented by a corresponding CHR constraint among the link variables of the 
I-Sets that it involves, namely the iset_member/2 (in this case, the first argu- 
ment is a ground FZ) value), iset_union/3, is et_inter section/ 3, iset_inclusion/2, and 
iset-difference/3 constraints. 

The satisfaction of X-Set constraints is ensured incrementally (see Section IX^ . 
For instance, the following rule is used for implementing the iset_intersection/3 
constraint. 

intersection_right_to_lef t @ 

iset_inserted(Iset3, Element) , 
iset_inter sect ion (Isetl , Iset2, Iset3) 
# _iset_intersection 
==> ensure_membersliip(Isetl .Element) , 
ensure_member ship ( lset2 , Element ) 
pragma passive (_iset_intersection) . 

The rule is activated when a new element is added to the I-Set represented 
by the third argument of an is et-inter section/^ constraint: this is notified by the 
isetJnserted/2 constraint, which implements the inserted event of Sect. 12. l1 The 
rule imposes constraint ensure-membership/2 on each of the other two I-Sets and 
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the element; if necessary, the element will be inserted into the I-Sets. Notice that 
ensurejmemhership 1 2 is defined so as to fail if the I-Set is closed and the element 
is not already in its known part. Constraint iset_intersection/S is declared passive 
for efficiency, because it is not necessary to generate code for it (Z-Set constraints 
as iset-intersection / 3 are imposed only at the beginning of the computation). 

Two more rules (not shown here for lack of space) manage the case of an element 
having been inserted into the first or second argument of the iset_intersection/3 
constraint. 

The close /I primitive of Sect. I2.ll is implemented by the following CHR: 

close_iset @ 

close(Iset), iset_open(Iset) # _iset_open 

<=> closed(Iset) 

pragma passive (_iset_open) . 

CHR constraint cJose/1 is imposed to close the TSet; the effect of this rule is to 
remove constraint iset_open/l for the I-Set, and to impose CHR constraint closed/1 
for the I-Set. Constraint closed /I also implements the event notifying that the 
argument TSet has been closed, which can interact with Z-Set constraints so as to 
propagate closure when possible. For instance, the rule of Sect. I2.ll is implemented 
as follows: 

closure_propagation_inclusion @ 
closed(Iset2) , 

iset_inclusion(Isetl , Iset2) # _iset_inclusion, 
iset_known(Isetl ,K1) # _iset_knownl , 
iset_known(Iset2 ,K2) # _iset_known2 , 
==> permutation(Kl,K2) I 

close(Isetl) pragma passive (_iset_inclusion) , 
passive (_iset_knownl) , passive (_iset_known2) . 

Predicate permutation/ 2 in the guard checks that the two TSets have the same 
elements. 

4-2 FD variables and constraints 

4-. 2.1 FD variables and domains 

FD variables are represented as CHR constrained variables. Their do- 
main is an I-Set; constraint :: /2 (see Section I2.3|l is implemented as 
the icsp-def-domain(Variable,Iset) CHR constraint, whereas the current do- 
main of the variable and its set of removed values are represented by the 
icsp-Curr_domain(Variable, (Present, Removed)) CHR constraint, where Present is 
the list of present elements and Removed is the list of removed elements. 



4-2.2 FD constraints 
FD constraints are represented by the fd-Constraint( ConstraintName, ListOfArgu- 
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ments) CHR constraint. For instance, FD constraint X < Z is represented by the 
f d_constraint (It , [X,Z]) CHR constraint. 

FD constraints are defined by the user simply as one or more clauses for the 
Prolog predicate fd_verify/2 needed to verify whether the constraint is satisfied by 
a list of ground arguments. This way of defining FD constraints supports non-binary 
constraints, and easy extensibility of the system. 

For instance, a possible definition of the FD </2 constraint could be 

fd_verify(lt, [A,B]) :- A<B. 

4.2.3 KAC procedure 

Candidate (see Section 13.1.1(1 elements for each variable are stored in the cur- 
rent_candidates(Variable,ListOfElements) constraint. 

KAC check over candidates is performed by building a support graph (see Section 
13.4. 2|) . Nodes of the graph are (Variable, Element) pairs. A pair is a node of the 
graph if and only if it is member of the list argument of the observed_candidates/l 
CHR constraint; an arc (indicating support dependency) is represented by the relies 
((VarljVall), (Var2,Val2), FDConstraint) CHR constraint, where FD Constraint is 
the FD constraint for which (Var2,Val2) supports (Varl,Vall). 

Graph construction is achieved by the following CHR rule: 

kac_check_start @ 

kac_unlock, 

current_cajididates(Var, [Csindidate I MoreCaindidates] ) 

# _current_candidates 
<=> current_candidates(Var ,MoreCandidates) , 
observed_candidate ( (Var .Ccindidate) ) , 
check_candidate ( (Var , Candidate) ) , 
!, f lush_candidates , end_f lush_candidates , 
kac_unlock pragma passive (_current_candidates) . 

Graph construction begins when there is at least one non-empty list of candidates 
for a variable: an element is chosen (in the current implementation, it is simply 
the first of the list), pair (Variable, Element) becomes the first node of the graph 
(constraint observed_candidate/l adds its argument to the list argument of con- 
straint observed-Candidates / 1) , and KAC check starts from it (check_candidate /2 
constraint); during check, new nodes may be added to the graph, which will be 
checked for support in their turn. When the construction is done, graph nodes are 
inserted into the current domains {flush_candidates /O and end_flush_candidates / {) 
constraints), and the procedure can start again over the rest of candidates. 

kac-unlock/0 is a constraint meant simply to start the KAC procedure. If there 
are no candidates when it is imposed, then if there is a variable with empty current 
domain an element is acquired for it which will become a candidate; otherwise, the 
procedure reaches quiescence. 
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4-2.4 Support seek 

Support seek for a (Variable, Element) pair is started by constraint 
check_candidate( (Variable, Element)). This constraint collects from the store all the 
FD constraints that involve Variable, and for each of them tries to find an assign- 
ment of all the involved variables that satisfies it (i.e., that makes goal fd-verify/2 
(see Section [4.2. 2|) succeed). Elements for the other variables are chosen following 
the priority described in Section Td. 4. II 

4-2.5 Support seek through element acquisition 

If no acceptable assignment is found among known, observed, and candidate ele- 
ments, then: 

• if the I-Sct domain of at least one of the other variables is open, a new element 
is acquired for one of the other variables; 

• if the I-Set domains of all the other variables are closed, failure is reported, 
and possibly backtracking is applied. 

Which variable should be chosen for acquisition among those with open domain is 
not obvious for non-binary constraints, and application specific heuristics could be 
useful; in this implementation the first variable is simply chosen. 

In the current system, element acquisition is obtained by asking the user for 
an element, and the TSet is closed in case of a predefined input from the user. 
Obviously, in practical applications, elements would be provided by an acquisition 
system, as in IjMailharro 1998|l . where the acquisition is done automatically by gen- 
eration of new component instances, or in IjCucchiara et al."l999bf) . where elements 
are provided by a low-level segmentation system. 

4-3 Constraints and rules for interaction between sorts 

Only one CHR constraint needs to be added to the solver to link the two sorts: 
iset-inserted(Iset, Element) , imposed when Element is inserted into the known part 
of Iset. This constraint is the implementation of the inserted/ 2 event described in 
Section O 

4.3.1 FD to I-Set link 

When a new element Element is acquired for a variable V whose definition domain 
is Iset, iset_inserted(Iset, Element) is imposed. This CHR constraint implements an 
event that triggers the X-Set constraint check. From a procedural point of view, 
this makes control pass from the FD solver to the I-Set solver. 

4.3.2 I-Set to FD link 
When imposed, iset-inserted(Iset, Element): 
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• first, interacts with the X-Set constraints involving Iset, as shown in Sec- 
tion O 

• then, inserts Element in the hst of candidates of all the variables having Iset 
as definition domain, for later support seek. 

The interaction with the X-Set constraints may involve new insertions, which will, 
in their turn, impose further iset_inserted/2 constraints. 

New candidates are added only when X-Set propagation has been completed, for 
the reasons explained in Section IT^ 

5 Related work 

I-Sets can be considered as streams with a set semantics (i.e., in an I-Set there are 
no repeated elements and elements are not sorted). Streams are widely used for 
communication purposes in concurrent logic programming f S hapiro 1987| ). Various 
communication protocols can be implemented using this simple yet powerful data 
structure ( [Shapiro 1989| ). An I-Set can only contain ground elements; this restric- 
tion prevents (open) I-Sets from being passed in an I-Set, but lets us achieve higher 
efficiency. 

The first results of our research in the ICSP framework are reported by Cucchiara 
et al. H1999a|l . where the ICSP model is proposed as an extension of the CSP model. 
In this model, variables range on partially known domains which have a known part 
and an unknown part represented as a variable. Domain values are provided by an 
extraction module and the acquisition process is (possibly) driven by constraints. 
The model has been proven effective in a vision system ([Cucchiara et al. 1999b|l . in 
randomly-generated problems l[Cucchiara et al. 1999a|l . and in planning l[Barruffi et al. 1999|l 
This work can be considered as the language extension and CHR implementation 
of the ICSP framework, maintaining it as the core of the propagation engine on the 
FD side. 

Operationally, achieving KAC has some similarities with achieving Lazy Arc 
Consistency (LAC) (|Schiex et al. 1996|l . LAC is an algorithm that finds an arc- 
consistent sub-domain (not necessarily a maximal one) and tries to avoid the check 
for consistency of all the elements in every domain. KAC looks for an arc-consistent 
sub-domain as well, but it is aimed at avoiding unnecessary information retrieval, 
rather than unnecessary constraint checks. 

Codognet and Diaz H199(i|l describe a method for compiling constraints in 
CLP(FD). There is only one primitive constraint {X in R), used to implement 
all the other constraints. R represents a collection of objects and can also be a 
user function. Thus, in CLP(F_D) domains are managed as first-class objects; our 
framework can be fruitfully implemented in systems exploiting this idea. 

Sergot (fBSS)) proposes a framework to deal with interaction with the user in a 
logic programming environment. Our work can be used for interaction in a CLP 
framework; it lets the user interactively provide domain values. 

Zweben and Eskey H1989|l propose an algorithm that evaluates domain elements 
only when necessary; domains are streams and constraints are filters on domains. 
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Dent and Mercer H1994|l show the effectiveness of such an approach when constraint 
checks are expensive operations. In our proposal, implementation of delayed eval- 
uation is quite natural and simple, even if our work is aimed at reducing domain 
values extractions, not constraint checks. 

Dynamic Constraint Satisfaction (DCS) IjDechter and Dechter 1988)l is a promis- 
ing field of AI taking into account dynamic changes of the constraint store such as 
the addition and deletion of values and constraints. The difference between DCS 
and our approach concerns the way of handling these changes. DCS approaches 
propagate constraints as if they worked in a closed world. Basically, in a DCS one 
can add or remove a constraint; thus, one can also add and delete domain elements 
provided that they are all known from the beginning. In an ICSP, instead, domain 
elements that are unknown can be requested and inserted in the domain. DCS 
solvers record dependencies between constraints and the corresponding propagation 
in proper data structures IjSchiex and Verfaillie 1 9931 so as to tackle modifications 
of the constraint store as soon as data change. In this perspective, we also cope 
with changes since the acquisition of new values can be seen as a modification of 
the constraint store. However, we work in an open world where domains are left 
open thanks to their unknown part. Unknown domain parts represent intensionally 
future acquisitions, i.e., future changes. 

Another DCS framework was given for configuration prob- 
lems l|Mittal and Falkenhainer 1990|l . This framework considers dynamicity 
in the set of variables; variables are introduced or removed during search by means 
of constraints. The aim is to find a solution where only some of the variables 
are assigned a value, while the others are inactive. However, differently from our 
framework, the set of domain values is given at the specification of the problem. 

Many systems consider implement sets, because sets have powerful description 
capabilities. In particular, some have been described as instances of the general 
CLP (A") framework l|JafFar et al. 1998|l . like {log} (jDovier and Rossi 1993llDovier et al. 19961 
IDovier et al. 200 l|l . CLPS ( |Legeard and Leg ros 199T|, or Conjunto l|Gervet 1997|l . 
Others apply an object-oriented approach fPuget 1992l|Puget 1994| |. 

In i^ooT llDovier and Rossi 1993llDovier et al. 1996llDovier et al. 2001|l . a set can 
be either the empty set 0, or defined by a constructor with which, given a set S 
and an element e, returns the set composed of S U {e}. This language is very 
powerful, allowing sets and variables to belong to sets. However, set unification 
and the propagation of other constraints has an exponential time complexity in 
the worst case. If we allow non-ground elements in an I-Set, we obtain a more 
expressive (although less efficient) framework, like {log}; we are currently studying 
this extension. 

Set variables ( |Puget 1992||Puget 1994| ) can range on set domains. Each domain is 
represented by its greatest lower bound and its least upper bound. Each element in 
a set must be ground, sets are finite, and they cannot contain sets. These restrictions 
avoid the non-deterministic unification algorithm, and give good performance re- 
sults; they are implemented in most Constraint Programming systems ( |Puget 1994| 
ISmolka 19951 ISK^Stus 20031 l(4ervet 19971 IK^Pa.rc 2001|l. However, these systems 
do not deal with problems in which some domain elements are not known; in fact. 
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the user must provide the least upper bound of each set, thus giving the universe 
set at the beginning of the computation. 

ILOG-Solver ( |Puget 1994| ) does not deal directly with those problems, but has an 
extension module, called ILOG-Configurator (Mailh arro 19981 IILOG 1999|l whose 
main added value is to implement open domains in a way similar to our system. 
This system is very related with ours, thus we give a more detailed comparison. 

Comparison with ILOG-Configurator. In Ilog-Configurator, there are variables 
called "ports" whose domains are defined by the set of instances of a given compo- 
nent type. The set of instances is not known in advance and instances are generated 
on demand during constraint propagation. In this way, domains of port variables are 
dynamically extended; a domain that can be extended contains an element called 
"wildcard" . 

Our system has many points in common with the one described by Mailharro 
H1998|l . To compare the two, the reader can refer to the following table: 



ICSP ILOG-Configurator 



FD Variables 
I-Set 

Known Part 
Unknown Part 
::/2 

Definition Domain 
Current Domain 
Removed Elements D"^ 
Inserted Event 



Port Variables 

Component Types 

Set of generated instances 

Set of not yet generated instances (Wildcard) 

Link port-type 

Set of instances of the target type 
Possible set of a port 

Instances set of the target type \ possible set 
Extension delta domain of ports 



The differences that we envisage between the two systems are the following. 
ILOG-Configurator is based on an object-oriented technology, while ours is based 
on logic programming; this is reflected in some specific choices made in the two 
systems. For example, both the systems reason about the possible closure of a 
domain. This information is carried by a special element, called "wildcard" by 
Mailharro H1998|l . while in our system it is the unknown part of the domain. In our 
system, if the continuation of the domain is a variable, other elements can be added, 
otherwise, if it is the empty set, the insertion of other elements will be forbidden 
by unification. This has a declarative meaning from a set viewpoint; while a set 
containing a wildcard must be updated through some destructive assignment, our 
formalization lets the user specify the value of a logical variable: the continuation of 
the domain will be extended, as in a stream. In other words, in the ICSP formulation 
we keep set membership and set inclusion distinct. In fact, in l|Mailharro 1998|l . the 
wildcard element represents a set of elements, but is also an element of the domain. 
Thanks to our formalization, some future extensions are possible: for example, it 
is possible to extend the type of sets in a domain, and to have domains that can 
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contain sets themselves, like in {log} l|Dovier et al. 1996|l . The propagation of FD 
constraints is operationally performed in a similar way (Known Arc Consistency 
propagation); however, the property of Known Arc Consistency (KAC), which was 
not defined by Mailharro H1998|l . enabled us to prove properties of the algorithms 
achieving KAC UGavanelli et al. 2004|l . 

Finally, in our framework it is possible to define I-Sets as the combination of 
other I-Sets with set operators. 

6 Conclusions 

In this work, we presented the implementation of a language that performs con- 
straint propagation on variables with finite domains when information about do- 
mains is not fully known, and its CHR implementation. Domains are channels of 
information, and are considered as first-class objects that can be themselves defined 
by means of constraints. The obtained language belongs to the CLP class and deals 
with two sorts: the FD sort on finite domains and the X-Set sort for domains. We 
provide a propagation engine for the FD sort exploiting known arc-consistency, and 
one for the I-Set sort, as well as a mechanism for their interaction. 
The source code of the system is available on request. 
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